home *** CD-ROM | disk | FTP | other *** search
/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / utils / maxidi22.lzh / MAXITECH.DOC < prev    next >
Encoding:
Text File  |  1992-06-05  |  13.6 KB  |  267 lines
  1. ;File name:    MAXITECH.DOC        Revised:    1992.06.05
  2. ;Created by:    Ulf Ronald Andersson    Created:    1992.02.07
  3. ;
  4. ;File purpose:    To document the release of 'Revised MaxiDisk 2.0',
  5. ;   - " -    and provide some deeper details than MAXIDISK.DOC does.
  6. ;
  7. ; Copyright:    Original released as PD FREEWARE by author:  Max Böhm  1987.
  8. ;         Revisions as PD FREEWARE by author: Ulf Ronald Andersson  1992.
  9. ;        
  10. ;
  11. ; As may be apparent from the general layout of this text, most of it had its
  12. ; origin in my source-file comments for MAXIDISK.S, and its support files.
  13. ; Some of this information will of course duplicate that in MAXIDISK.DOC,
  14. ; but much of it is found in this file only, since I believe that few users
  15. ; of MaxiDisk will care very much how it works, as long as it is reliable.
  16. ;
  17. ;
  18. ;    Revision 2.2 updates of May 1992:
  19. ;
  20. ;    1. The routine that searches for the MPB pointers of TOS has been
  21. ;       improved, and now functions on all known TOS versions.
  22. ;
  23. ;    2. Some sector handling routines have been improved, though this
  24. ;       may be masked by the delays caused by packing.
  25. ;
  26. ;    3. MaxiDisk 2.2 has been tested error-free on several TOS versions
  27. ;       ranging from TOS 1.0 through TOS 1.4 to KAOS 1.4.2.
  28. ;       Since no TOS-dependent features are used it should always work.
  29. ;
  30. ;       Note, however, that COPY.TTP may fail on some ancient TOS's,
  31. ;       because of the bug in the gemdos function 'Malloc'.
  32. ;       Such failure only means that some files will be left uncopied.
  33. ;
  34. ;       Unfortunately the present release of TOS 2.6 has a bug in the
  35. ;       code for 'warm' reset, such that no reset-proof ramdisk seems
  36. ;       to be possible under this TOS !!!  (I will investigate this)
  37. ;
  38. ;
  39. ;    Revision 2.1 updates of March 1992:
  40. ;
  41. ;    Several routines were trimmed for higher efficiency, and one byte
  42. ;    in the simulated 'boot' sector was adjusted.
  43. ;
  44. ;
  45. ;    Summary of changes from old MaxiDisk to Revised Version 2.0:
  46. ;    ------------------------------------------------------------
  47. ;
  48. ;
  49. ;    1. I have implemented the XBRA protocol for all 3 vectors used.
  50. ;       This was one of the two reasons I made this revision.
  51. ;       The affected vectors are:
  52. ;       1) hdv_bpb        called by OS to identify disk format
  53. ;       2) hdv_mediach    called by OS to detect media changes
  54. ;       3) hdv_rw        called by OS for all read/write functions
  55. ;       During boot MaxiDisk checks if phystop points to the legal
  56. ;       identification code for MaxiDisk, which means warm boot.
  57. ;       But regardless of whether a warm or cold boot is indicated,
  58. ;       all 3 XBRA chains are tested to see if any XBRA named "MAXI"
  59. ;       is already in use.  If so, no new vectors are installed, and
  60. ;       an error message is given stating this situation.
  61. ;
  62. ;    2. I have modified the memory protection method, so that MaxiDisk
  63. ;       now is compatible with OVERSCAN.PRG and other programs that
  64. ;       previously could crash MaxiDisk (especially when nearly full).
  65. ;       (OVERSCAN.PRG must be started after MaxiDisk to function well)
  66. ;       The need to use it with OverScan etc., was of course my other
  67. ;       main reason to make this revision (by now practically rewrite).
  68. ;       This modification consists of several parts.
  69. ;       1) _memtop is adjusted in addition to phystop
  70. ;       2) the RAM block reserving high RAM is shrunk, and then released
  71. ;             using normal Mfree, so no garbage MPB's remain.
  72. ;       3) All data between _memtop and phystop is moved down into the
  73. ;          new corresponding area, without assumptions about screen size.
  74. ;       4) _v_bas_ad is adjusted without assuming either any screen size
  75. ;          or identity with _memtop, only that it lies somewhere between
  76. ;          _memtop & phystop, and the move will be a multiple of 512.
  77. ;          The move is not made direct in hardware, nor by calling XBIOS,
  78. ;          nor by poking _v_bas_add.  I simply store the new value in the
  79. ;          'screenpt' variable and await a VSYNC. Any screen handler which
  80. ;          has the physical screen in some other, immovable, area need
  81. ;          only ignore 'screenpt', so hopefully most large screens are OK.
  82. ;       5) A (hopefully) TOS independent routine searches all of OS RAM
  83. ;          to find the MPB root pointers enabling most of the above.
  84. ;          Should it fail, an error message will be given.  This does
  85. ;          NOT have to mean TOS incompatibility.  It may be due to some
  86. ;          earlier boot program messing with MPB's or _memtop, so do try
  87. ;          rearranging the auto folder in such cases.
  88. ;
  89. ;    3. I have patched the BPB handling to ensure better efficiency
  90. ;       when using huge ramdisks, which old MaxiDisk hardly packed.
  91. ;       BPB is still non_standard, of course, in that it has as many
  92. ;       logical clusters as there are physical sectors, but that is
  93. ;       how packing was made transparent to the OS.
  94. ;       Internally MaxiDisk uses linked packed data blocks of free size,
  95. ;       so the loss of space due to cluster size never occurs.
  96. ;       The packing itself also makes RAM storage more efficient, so that
  97. ;       the extra clusters' FATs originally marked BAD can be released,
  98. ;       simply by marking these clusters as FREE in the FAT sectors.
  99. ;       But to do so the FAT sectors and internal data block pointers
  100. ;       must be dimensioned to handle more data than the physical size.
  101. ;
  102. ;    4. I have completely rewritten the data block allocation code.
  103. ;       The original seemed to be compiler-generated rubbish.
  104. ;       It did work, but inefficiently, so I replaced it with a better
  105. ;       routine of my own design.  The main task it accomplishes is
  106. ;       to reclaim blocked ram by fusing released data block chains
  107. ;       into the chain of free blocks.  But the old routine did not 
  108. ;       always succeed in also fusing all adjacent blocks, so as to make
  109. ;       larger contiguous data blocks, and releasing some block links.
  110. ;       The new routine always does this, so whenever you clean out all
  111. ;       files from MaxiDisk, the data blocks all fuse into one huge block.
  112. ;       Thus you can always start over without any remaining fragmentation.
  113. ;
  114. ;    5. I have completely rewritten the pack/unpack routines, and have
  115. ;       changed the packing algorithm a bit. This makes packing a bit
  116. ;       tighter and faster, although no packing ramdisk can be FAST.
  117. ;       At present the new MaxiDisk seems to run at one eigth the speed
  118. ;       of QWIKDISK, as measured by QINDEX, which will do for me.
  119. ;       To be specific, each two-byte packing code, can now represent
  120. ;       a sequence of up to 64 bytes instead of the original 63 bytes.
  121. ;       Nonpacked sequences are limited to 128 bytes instead of 127.
  122. ;       A special marker has been implemented to allow completely
  123. ;       nonpacked sectors, used whenever packing proves inefficient.
  124. ;       So regardless of data complexity, you always have room for at
  125. ;       LEAST so much data as is presently indicated by the free FATs.
  126. ;
  127. ;    6. I have eliminated a lot of compiler-generated garbage-code, and
  128. ;       unneeded huge file arrays (that have NEVER been used !!!).
  129. ;       Also the insane program startup sequence, which turned the data
  130. ;       and BSS sections upside-down.  (Really...!)
  131. ;
  132. ;    7. I have also patched and streamlined each and every routine that
  133. ;       remains in the program to get rid of that silly compiler stuff.
  134. ;       eg:    "LEA    (A0),A0"  and such-like ridiculous nonsense.
  135. ;
  136. ;    8. I have added a simulated "boot" sector, since that area contains
  137. ;       the information which OS floppy routines use to boot their BPB's.
  138. ;       Programs that circumvent GEMDOS sometimes access this data,
  139. ;       instead of using BIOS Getbpb. Such programs will not work with
  140. ;       ANY RAM disk which do not initialize this area.  MaxiDisk now
  141. ;       sets the "boot" sector according to its current size in RAM, this
  142. ;       has been tested with MemFile 3.0 which can now access MaxiDisk
  143. ;       through the sector editor, something not possible before.
  144. ;
  145. ;    9. I have amended the 'hdv_mediach' routine to flag '1' on each call
  146. ;       that occurs directly after MaxiDisk has altered the allocation of
  147. ;       free FAT's. This flag is returned only on each first such call.
  148. ;       Its purpose is to force any programs that try to preallocate FAT's
  149. ;       to recognize the need to read the FAT sectors again.  This has not
  150. ;       yet been extensively tested, but few programs show the need for it.
  151. ;       It may help prevent cache'ing programs from hiding packing.
  152. ;
  153. ;NB: As of the present version (Feb 20 1992), I am not aware of any problems.
  154. ;    Some will probably crop up later on, as more users test it.
  155. ;    I can only test it against such software as I have, so users with
  156. ;    different interests may have a better chance at finding faults :-(
  157. ;    All problems that I have seen with other RAM disks have at least been
  158. ;    removed or kept out of this MaxiDisk, and the code is much clearer and
  159. ;    easier to work with since I removed the last traces of the compiler.
  160. ;    Thus I am confident of being able to fix future problems, if they come.
  161. ;
  162. ;
  163. ;    I will surely improve the program even further, but at present I
  164. ;    think I have achieved what I set out to do.  Which was to revive
  165. ;    this great idea of a packing ramdisk, in a version acceptable by
  166. ;    modern standards and compatible with other modern programs.
  167. ;
  168. ;
  169. ; Below follows an assorted mix of remarks and information:
  170. ;
  171. ; Original MaxiDisk seems to have been created with a C compiler.
  172. ; The startup code extended the BSS area with $2000 bytes stack,
  173. ; then moved the contents of the DATA area to the end of the
  174. ; original BSS area and zeroed the remainder of both areas.
  175. ; A4 was set pointing to the moved data, which were strings,
  176. ; so strings were indexed positively, other STATIC's negatively.
  177. ; Several Kbyte there were devoted to C IO functions not used !
  178. ; A6 was used for allocation of AUTO data.
  179. ; All this has been abolished, except for the use of A4 and A6.
  180. ; The use of A4 is altered, so all indexes are positive.
  181. ; DATA and BSS sections now follow standard.
  182. ;
  183. ;
  184. ;
  185. ; MaxiDisk high memory variable offsets, relative to phystop
  186. ;
  187.     RSRESET
  188. _maxi_date        rs.l    1    ;long BCD identification date == MAXIDATE
  189. _maxi_drive        rs.w    1    ;word MaxiDisk drive number (0..$1A)
  190. _maxi_size        rs.w    1    ;word MaxiDisk Kbytes data capacity
  191. _maxi_CHAIN_p        rs.l    1    ;-> First free block in data block area
  192. _maxi_dspace        rs.l    1    ;long == free space in data blocks
  193. _maxi_pspace        rs.l    1    ;long == space held by free block pointers
  194. _maxi_reserve_1        rs.l    1    ;RESERVED for future changes (BEWARE)
  195. _maxi_reserve_2        rs.w    3    ;RESERVED for future changes (BEWARE)
  196. _maxi_bpb        rs.w    9    ;9 words BPB data
  197. _maxi_MAP        =    __RS    ;map of data block pointers for logical sectors
  198. _maxi_headend    = _maxi_MAP
  199. ;
  200. ; twice as many logical sectors may be used, than would be for unpacked data
  201. ; so the number available is dependent on how data can be packed.
  202. ;
  203. ;
  204. ; The BPB is non_standard, in that twice the number of physical clusters
  205. ; is used for "bpb_data_clusts". Those not available have FATs = $FFF7 .
  206. ; As clusters are stored in packed format, these "BAD" clusters can then
  207. ; be released, by changing their FATs to $0000 (free).  (INTEL format !)
  208. ; Unfortunately, the original allowed packing only on small RAM disks,
  209. ; since insufficient extra FATs and map pointers were added to large ones.
  210. ; This seems to have caused some confusion amongst the subroutines, as to
  211. ; whether "bpb_data_clusts" means sectors or clusters available.
  212. ;
  213. ; I have fixed it so all sizes use "bpb_data_clusts" at twice the size
  214. ; of the physical data area requested, with the same number of map pointers.
  215. ; This means all sizes have an extra overhead cost, but this is compensated
  216. ; for by the area gained through packing.
  217. ; EG:    Size requested        = 1200 Kbyte    = 1 228 800 bytes
  218. ;    Data with worst packing    = 1200 Kbyte    = 1 228 800 bytes
  219. ;    Total RAM cost        = 1256 Kbyte    = 1 286 144 bytes (excl TPA)
  220. ;    Stored test data    = 1586 Kbyte    = 1 624 652 bytes
  221. ;    Data with ideal packing = 2400 Kbyte    = 2 457 600 bytes
  222. ; This was tested with the files on my program testing diskette, which is quite
  223. ; dominated by program files. Text files should pack even tighter.
  224. ;
  225. ; Some rules of thumb follow:
  226. ;
  227. ; 1. Data room will always achieve the size you requested in booting,
  228. ;    even if no effective packing can be done. (eg: many LZH-files)
  229. ;
  230. ; 2. RAM cost will be approximately requested size + 5% + MaxiDisk TPA.
  231. ;    The TPA is presently appx 12 Kbyte.  No other RAM costs can occur
  232. ;    once MaxiDisk is running, it only Malloc's during initialization.
  233. ;
  234. ; 3. If you expect to have a normal mix of files (not ONLY LZH archives!),
  235. ;    you can expect a useful area well over request_size + 25%.
  236. ;    Note that this is appx total RAM cost + 20%, so it may even then be
  237. ;    possible to have data exceeding total RAM size on your computer !!!
  238. ;
  239. ; 4. Simpler data gives better packing, so pure text files may well approach
  240. ;    the absolute limit of twice the request-size.
  241. ;
  242. ; 5. The only case when stored data will not achieve the requested size, is
  243. ;    when many very small files use up all FAT marks. This will prevent OS
  244. ;    from knowing that any area is free, since OS only understands clusters.
  245. ;
  246. ;
  247. ; I can not promise to supply any help or advice on request since, after all,
  248. ; this is freeware.  I may have to devote my time to earning som money too.
  249. ; Still, if I have the time, and feel in the mood, I might try to help out.
  250. ; In case you wish to reach me, my address is as follows:
  251. ;
  252. ;    Ulf Ronald Andersson
  253. ;    Höders Väg 7
  254. ;    S-145 70  Norsborg
  255. ;    Sweden
  256. ;
  257. ; (In case you are unsure about nordic characters, use 'Hoders Vag 7'.)
  258. ; (This is of course incorrect, but will be understood by post office.)
  259. ;
  260. ; For cases of dire emergency, my phone number (within sweden) is:
  261. ;
  262. ; 0753 - 84 105
  263. ;
  264. ; (I believe foreign callers need to remove the initial zero though.)
  265. ;
  266.        -------------------- End of file MAXITECH.DOC --------------------
  267.